This is an important fact to know when using these functions,
so it belongs in their jsdoc.

This corresponds to the recent changes that made the actual
content of a Narrow include a stream ID and not a stream name.

This is one place where we've correctly used stream IDs, not names,
from the very beginning: 10ba802 in 2017-01, where we first started
handling these events.

Our goal in this series isn't yet to resolve the issue zulip#3918, but to
get to where it's easy to *audit* our code for the remaining things we
need to do to complete it.

There are two kinds of searches one wants to do in such an audit:

 (a) Searching for *known* instances of the issue, in order to find
     remaining items to work on and eventually to confirm there are
     none left.  For this, we want simple systematic patterns to
     search for.

 (b) Searching for yet-*unknown* instances of the issue.  This is
     inherently fuzzier; one searches for patterns like /stream.name/
     or /streamName/ or even /stream.*name/i to try to find code that
     refers to stream names, which produce a lot of matches including
     some legitimate uses and some that aren't even about stream names.

     For this, the main thing we can do is make it as simple as
     possible when reading such search results to confirm that a given
     spot is a known instance of the issue, in order to focus on those
     that might be unknown.

For the sake of (a), we add TODO-3918 comments at each instance
that's actionable on its own, and references to zulip#3918 where there's
another TODO comment that the fix blocks on.

For the sake of (b), when a given instance of the issue pops up in a
number of scattered places (like the definition and each call site of
a given function that takes a stream name), we add references to zulip#3918
at each of those places even when we only need one TODO comment.

This commit adds such comments for two related instances of the issue,
and the next few commits will add them for others.

This property should be optional, because the code still supports
server versions where it's absent.  (As reflected in the comment
there, and more concretely in FcmMessage.kt where it handles the
same user_id property.)

Then marking it optional raises the question: why doesn't Flow
tell us about an error?  In fact we were already not assuming the
property is present: extract.js explicitly handles the case where
it's absent.  But also it turns out that even if we were making
that assumption, Flow wouldn't be able to make the connection,
because we don't use these types in code.  That's different from
how we use most of our API types -- so document it explicitly
with some comments, to help avoid surprises in the future.

The repeated mentions of the issue may look redundant.  But this
way, when the TODO-3918 comments are deleted in the course of
taking care of them, the other references will naturally remain.

That will help with grepping for remaining places we're using
stream names, even while those places aren't directly actionable
because they're blocked on a minimum-server-version upgrade.

This makes it easy to, say, flip `name` from read-only to write-only
in order to audit the remaining uses of stream names.

Or in some cases, there's an existing TODO-server comment, and we
just add a reference to the issue.  (These are places where there's
nothing to be done about the issue before simply dropping support
for older servers, so the proper thing for the TODO itself to refer
to is the server version.)

I believe this covers all remaining instances of zulip#3918.  That means
that every place we refer to a stream name should either:
 * be a legitimate use of stream names;
 * have a TODO-3918 comment; or
 * have a different kind of TODO comment (as it happens, always a
   TODO-server comment), and a mention of zulip#3918.

As a result, a search like `git grep TODO..3918` will find all the
remaining places we need to act in order to close issue zulip#3918,
according to the plan I described here:
  zulip#3918 (comment)

The broader search `git grep -w 3918` will additionally find all the
places that are (known) instances of the issue but are blocked purely
on server upgrades.

Our types say this is a string, so the `|| ''` can't have any
effect.

Just to be sure there wasn't a latent bug somewhere that this
was hiding, I went and traced where this data comes from.
That `streamName` property comes from these lines in
getUnreadStreamsAndTopics, in unreadSelectors:

      const { name, color, in_home_view, invite_only, pin_to_top } =
        subscriptionsById.get(streamId) || NULL_SUBSCRIPTION;

      // …
        streamName: name,

So it's the `name` property either of an actual subscription,
or of NULL_SUBSCRIPTION.

In an actual subscription that's a string, and for that matter
shouldn't be empty.  In NULL_SUBSCRIPTION it's… the empty string.
So effectively we're already doing this fallback up in
getUnreadStreamsAndTopics, where we construct this data in the
first place.

It's not clear that that's the right answer either, but let's at
least do the fallback just once.  We're already doing it
systematically there (for this and several other properties) and
haphazardly in this file (which already has another reference to
streamName without this fallback), so let it be there for now.

This was only used for invoking the callback, which no longer takes it.

This is NFC except in the case where the message's stream ID and
stream name don't match; in that case it fixes a bug.

This way, the use sites are now in the same situation as they would
be if passed a whole Stream object.  That makes it entirely their
responsibility whether they use the stream's name, either
appropriately or inappropriately.

As it happens, there's one callback that uses it appropriately (to
generate a Zulip-flavored-Markdown stream reference in autocomplete)
and one that uses it inappropriately.  The latter is because that's
what some API methods take, and already has appropriate comments.